Hi Tom,
We have an aluminum bar that we're trying to cut using G-code generated from CAM software.
The CAM implements trochoidal milling, which uses a long section of the cutter. That makes our 2 mm bit sensitive to any misplacement of the spindle.
We generated two versions of the G-code, one with a more aggressive stepover than the other.
When we run either version of the G-code with KMotionCNC, we get a number of anomalies. The first operation is to cut a 3.429 mm diameter hole, by spiraling the bit slowly down into the material. During this operation, both X and Y motors are required to move in synchrony to effect a circular motion. There is a stuttering noise from the motors as the hole is cut with KMotionCNC.
Using Mach3, there is no stuttering noise. Instead, both axes move without making more than the noise of the v-bearings against the rails that support the axes.
At times when running the code with KMotionCNC, there is a "creaking ship" noise. I think it's the Y axis motor, but I can't be sure, due to the fact that the gantry is in motion in both X and Y. Occasionally, for seconds at a time, there is a noise like a ship in high seas, being stressed to the point that its planks shift against each other. After a period of time, the noise will go away, for a minute or more, and then it will come back. The occurrences seem random, not tied to what kind of movement is being made. I took video of the noise. It's available at the URL
Running the same G-code with Mach3, there is no such noise.
Unfortunately, running the G-code in Mach3 is not without a problem. When running the more-aggressive version of the G-code, every few minutes, there is a "bump" from the axis motors, which sounds very much like the sound which happens when the axes are enabled.
The third "bump" that occurred (the first when actually cutting aluminum) coincided with the 2 mm bit breaking.
When the bit broke, I initiated a feedhold in Mach3. Then, since the bit was already broken, I loaded the less-aggressive version of the G-code and started the file from the beginning. I noticed fewer "bumps" using this code, but there was one, and I suspect that it would have broken the bit, if there had been one.
After the "bump", but not immediately, I got an error message: "Unexpected Motion Buffer Starved". Until the "OK" button was clicked, nothing happened. I took a screen shot of this condition - it's attached.
Continuing after the first "Unexpected Motion Buffer Starved" message yielded two more "Unexpected Motion Buffer Starved" messages within 10 - 20 seconds of operation, at which point I abandoned my experiment.
I believe that KMotionCNC has a number of issues in interpreting the G-code. Based on the comparison, we're planning to continue with Mach3.
Further, I suspect that the Dynomotion plugin is causing the "bumps" when running under Mach3. It sounds like a very high acceleration is commanded when it shouldn't.
How can I help track this down, so that its cause can be identified and fixed?
I suppose collecting Position, Dest, and Output during the "bump" might be useful. Is there any other information that should be collected as well? Is it possible to know what lines are being executed in Mach3 at a particular time, so that could be correlated with what's happening on KFLOP? I'd like to know if the bumps always happen associated with particular G-code.
Also, could you tell me a bit about how the Dynomotion plugin works with Mach3? What information does Mach3 provide to the plugin? I don't imagine it's just step/dir. I'm curious as to how much processing the plugin does on the data; for instance, does it do linear interpolated motion? It almost has to. Does Mach3 ask the plugin to move in line segments only? Or arcs as well?
Thanks,
Hugh
